Software Product management isn’t about creating products...
For any product folks reading this who have just spat out their coffee, allow me to explain. How many product managers do you know that have actually led the creation of a net new, greenfield product? I don't know many. In the modern investor funded software startup landscape it is more often founders that lead products in their early stages. Typically a devoted product specialist is only introduced after a funding event or period of growth. Therefore I'd argue that it's a much more common scenario that product people inherit products rather than creating them.
Why is this important? This pattern is critical to understand because for any product folk working in startups. The first 6 month to 1 year product strategy is going to be dictated by decisions made before you rocked up. And because you never know what you're going to get.
The shapes of inheritance
It's easy to oversimplify any challenges in the state of products that you inherit under the banner of 'tech debt'. But product debt can come in many forms, and I think a more nuanced view may help us to understand these situations better. So to that end - here are a few shapes I've seen that you might find familiar :
Poor PMF
This is when a PM takes on a product that solves a problem for a few customers but isn't gaining wider market traction. The small customer base who rely on the existing features makes it hard to pivot, but there is little growth opportunity with the product as it is. Competitors more aligned to the market are accelerating into the distance.
This is a tough situation. Not every PM gets the option to jump on board with the next unicorn startup and sometimes taking a role with a revenue making but low growth product is the best option available.
What this looks like to the PM
- Sales are asking for competitive capabilities which aren't possible to add to the product as it stands
- Product discovery uncovers problems and opportunities you are not well placed to solve
- Too much time is spent poring over the product trying to find a value for proposition to take it to new customers
A sales led swiss army knife
I've encountered this situation when a company doesn't have a strong product and has had to resort to 'closing code' to win every deal. At best this results in a host of little used and incompatible features, at worst you end up up with a cluster of standalone products connected only by style and brand. Sunsetting is difficult as each feature is contracted in to a major customer. Trying to build out common features is impossible as no two customers use the products in the same way and every new sale involves custom work.
What this looks like to the PM
- Sales have an eye watering list of options to sell with little understanding of which to present to which customer segment
- The customers are demanding a more coherent product and reporting experience but behind the scenes they're using a mess of disconnected data and features
- No-one knows if certain features even work together and major issues are uncovered with alarming regularity as novel feature combinations are sold.
- Different approaches are used to solve the same problem across the portfolio so customer configuration is a confusing experience and your service teams are the only ones that really know how set things up
Too narrow a domain mapping
This happens when there is a genuine and valuable problem but the solution created doesn't map to it well as it's far too aligned to one specific case. This is a challenge I've seen with products where a single main customer or stakeholder has led the product decisions in the early stages (agencies and consultancies trying to leverage their bespoke tools for a wider market also struggle with this). The features and underlying data structures will align to one specific instance of the problem domain, often a specific integration one customer is using, but lack the flexibility and extensibility needed to grow the product to address the wider market opportunity.
What this looks like to the PM
- Nothing you want to add quite fits how the existing product works
- Adding what appear to be simple features is prohibitively expensive
- Trying to extend the product to new use cases would require duplicating most of the database
The technology won't support the rate of growth.
Simply put - this is where at the rate the product use is growing, a part of the tech stack will cease to function effectively soon enough to present a tangible risk. While this could be due to poor technical choices, it can also be a sign of sensibly avoiding over-engineering at a stage it wasn't needed. The need for scale is, after all, a sign of a market fit some products never achieve. This article from Klaviyo is a great example of a company having a solution that allowed them to scale to a point, but rearchitecture was needed to grow further.
The obvious risks this situation presents to the incoming PM are that the time to address the problem is greater than the engineering runway available, and solving the problem involves diverting effort away from anticipated new features. It's therefore vital to have a handle on the impact timelines of the problem to ensure you factor in the necessary work before running out of road.
What this looks like to the PM
- There's a huge technical backlog project that has been repeatedly deprioritised to focus on new features
- Performance of background and data processes has started impacting user experience
- There's tension between CTO and CEO about devoting time to the problem
- More and more time is being devoted to engineers ‘plugging the gaps’ and freeing up time to work on a new approach is getting harder
You can't just stop
Unless you start your own company, as a product professional you're probably going to hit one of these scenarios at some point as you step into a new role and take over the product reins.
One thing to flag up is that - in the face of some of these challenges you will probably get a strong push from engineers to rewrite pretty much everything. This is an understandable response - the allure of a clean code base with shiny new technology has a strong pull. From a product and ROI perspective this is an extreme option and hard to justify.
You will also get a strong push from the CEO and commercial teams to deliver new features. The situations I've outlined here will almost certainly result in a slowing of team velocity over time and one of the expectations of you coming in may be to 'speed things up'.
In early stage companies maintaining momentum is vital both in terms of growing the product but also giving the wider team confidence in delivery. Nothing puts talented sales and marking folks off more than a product that isn’t changing - and full scale rewrites rarely deliver the value promised in the time expected.
Taking the right Approach
So how do we strike the balance? To be honest I have as many questions as answers on this, I've certainly not found any silver bullets. Here are some approaches I've found useful.
Present a strategic position
As Richard Rumelt outlines in 'Good Strategy, Bad Strategy' a strategy requires a solid understanding of current position. The top priority for any incoming PM is therefore to find out as quickly as possible what they have inherited and present the state of play clearly to the CEO and senior team. Only then you can go on and present an achievable product strategy.
Use sponsor initiatives to drive change.
Instead of flat rewrites an approach I have used multiple times is to tackle problem areas through product initiatives. If we need to rework an area of the product let's look at what the next valuable iteration of that area could be and build to that. In this way we at least maintain new value through the roadmap while tackling our debts. The risk here is a perception that these features are taking longer than they should, so this needs to be supported by strong communication on the underlying benefits of the rework additional to the immediate feature being delivered.
Start investing in the future.
A lot of early stage product decisions are entirely tactical as founders try to find a market fit. Joining as the first product hire, particularly off the back of an investment round, is the right time to start investing in future growth and it's your responsibility to carve out time in the roadmap for that. Starting research initiatives to understand and de-risk the biggest challenges build vital company momentum towards tackling them.
Don't be scared to shake up the roadmap.
If you are truly stepping into an empowered product leadership position then it's your responsibility to drive change where it is needed, even if this isn't the direction that was expected when you joined. Dropping unnecessary developments is as important a step here as creating new ones. I have terminated a number of engineering initiatives in the early stages of a role simply because the proposed benefits didn't justify the investment. Any changes will obviously need to be backed by reasoning - but highlighting the absence of supporting evidence behind a development is enough for you to reprioritise.
Inheritor Beware
Inheriting responsibility for a product is a risky time. No matter how much you look into a company in advance you never know the full picture until you get through the door - in every role I've stepped into there have been surprises. You may assume I'm writing this because of my current role. This isn't the case - while like every company we have challenges, but it's actually because I'm in a very positive situation right now that I feel I can openly write a post like this.
This hasn't always been the case. Sometimes it's gone too far. Sometimes the lack of addressing the big problems takes a company to a point where they run out of capacity to fix them without basically rebuilding from scratch. If things have been allowed to reach this point then a realistic assessment of the situation is not what the CEO wants to hear and you've probably been brought in to magically make development go faster. If that's the case then at least you have fair warning that the expectations of the role are unachievable. As influential tech recruiter James Jordan wrote in this great post - there are many reasons for short tenure in product roles and a mismatch of expectation on what's achievable is a common one.
Caveat emptor is the latin for 'buyer beware' - perhaps a more appropriate term for product managers is caveat heres or 'let the inheritor beware'.
Photo from: https://picryl.com/
Post a Comment